home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Zoom 2
/
Zoom - Release 2 (1996)(Active Software)[!].iso
/
music
/
utilities
/
octamed4devkit
/
mmd_fileformat
< prev
next >
Wrap
Text File
|
1993-09-02
|
3KB
|
61 lines
-----------------------------------------------------------------------------
MED/OctaMED MMD0/MMD1/MMD2 file formats
written by Teijo Kinnunen (30.05.1993)
Revision 2
$VER: MMD_documentation 2 (30.05.1993)
-----------------------------------------------------------------------------
Background
~~~~~~~~~~
A couple of years ago, when programming MED V2.1, I needed a file format
for MED modules. The only "module" format in MED V2.0 was the Sng+samples
format. Although it produced compact files, it was very difficult and
tricky to read in. Therefore, I designed a new file format that would be
easy to use in module player programs etc. This file format was named
'MMD0' (Med MoDule 0). The limitations in the MMD0 block format forced me
to create a new file format for OctaMED Professional, this format is
'MMD1'. It's mostly the same as MMD0, except the block structure is
different. Another new format is called 'MMD2', this extends some of the
old limits and provides a couple of new features
Design concepts
~~~~~~~~~~~~~~~
One of the main goals was to make MMD's (MED modules) as extensible as
possible. This would have been easy to implement with IFF-style chunks.
However, this method is obviously not the best for play-routine use.
Therefore, MMD's are implemented in quite an extraordinary way. They
consist of structures (similar to C structs) and pointers. In a module file
pointers are defined as offsets from the beginning of the module. This way,
a particular structure can be read just by Seek()'ing using the pointer as
the offset from the beginning of the file. When a module has been read into
memory, it has to be relocated before it can be used (the relocation is
done simply by adding the address of the module to the pointers).
As with the Amiga OS, a MMD file does not contain absolute addresses.
There's a module header structure at the beginning of the file. This
structure contains pointers to different parts of the module. And you
*MUST* use these pointers. You may NOT expect that the song structure is at
offset $00000034, for example. Although it usually is, this may change in
future releases. In addition, it's possible that a structure even doesn't
exist (the structure pointer is NULL). Therefore, you *MUST* check the
structure pointer before accessing the structure. Finally, when writing
MMD's you *MUST* set undefined/reserved fields to zeros. More finally, you
*MUST* align all structures to even boundaries! (I forgot the alignment in
MED V3.00 save routine, resulting Guruing modules under some conditions :-(
The module header
~~~~~~~~~~~~~~~~~
This structure must exist at the beginning of each MED module file. Each of
the structure members are described FULLY on the programmers disk that is
available from RBF Software. (See Programmers drawer)
In multi-modules, there are header structs for each song. (The subsequent
header pointers can be found from the expdata structure. Multi-modules
should have the same smplarr pointer in every header.) Older MEDs which
don't recognize multi-modules consider a multi-module as an ordinary module
(only the first song is loaded).
Please see the MMD.txt in ProPlayer drawer for details FULL and complete info.